1. The Field of the Invention
This invention relates to systems, methods, and computer program products for efficiently retrieving information from a network service using SOAP-based algorithms.
2. Background and Relevant Art
As computerized systems have increased in popularity, so also have the needs to distribute information on computer systems in networks both large and small. In general, computer systems and related devices communicate information over a network for a variety of reasons, whether, for example, to simply exchange personal electronic messages, to sell merchandise, provide account information, and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with sharing data and resources on a network have also increased.
For example, when a user accesses content from a web service (e.g., application at a web server) using a conventional web browser, the user typically does so by typing a Universal Resource Identifier (“URI”) into an address portion of the browser, or by clicking on a hyperlink to the content that is found in a different Internet web page. The web browser, in turn, will implement one or more functions over an appropriate protocol for accessing content at the URI. For example, in the simple case of an Internet web page, a Hypertext Transfer Protocol (“HTTP”) sends the request for content using a “get” command, which has the URI as a parameter (e.g., “GET(URI)”). When the computer system addressed by the URI receives the command, the computer system interprets any other parameters found in the URI, and sends the requested content back to the user, if available. Other computing languages (e.g., XML, etc.) that are layered on top of HTTP typically use the same “Get” command for sending requests.
Unfortunately, there are a number of disadvantages to accessing web content using the conventional Get command through HTTP. For example, one aspect of conventional HTTP is the notion that any reference (e.g., file, application, or other resource) that is to be accessible over a network will typically need to be addressable by a URI, as follows.                http://www.host.com/file.htmlUnfortunately, HTTP also has the limitation that all information associated with a certain request is also contained within the URI. For example, a URI for content that is found as the result of a query, or perhaps includes an update parameter, might include the query function calls and related parameters as part of the URI, as follows.        http://www.host.com/dirl/file.html?query-recentinformation.about.artist=xyzOf course, these sorts of URIs can be much longer and much more complicated than the foregoing example(s) depending on the nature of a given request.        
For example, a conventional online map service may have a distinct URI for each portion or view of a requested map. The URI is typically very long and complicated, and refers to a separately created map file, which represents a portion of the map for the entire city. In one instance, the server generates each separate map file for a city segment when the user selects the given city. Any time the user requests a higher view, or a closer view, or a more eastern/western or northern/southern view of a particular aspect of the city, the user selects a unique URI for that particular view, which corresponds to a separate map image. As such, an image map for any given city might have tens, hundreds, or thousands of different associated files for a requested city, which are each referenced by a unique URI.
The length or complexity of the URI, however, is only part of the difficulty with present HTTP request algorithms. In particular, despite the amount of information one can place in a URI, the amount, type, or method by which information is received is not very configurable. For example, the HTTP Get algorithm is typically limited to requesting X, and if X is available, the server returns X, regardless of size, amount, or any other limitations. With respect to the online map example, the client application requests a separate URI for each portion of a certain map, and receives all of the map contents found at the respective URI.
In some cases, the user can constrain the HTTP Get request for more granular information, such as requesting all versions of a city block prior to ten years ago. Unfortunately, more specific or granular requests often require ever-more complicated, lengthy URIs that contain the additional parameters used to constrain or enhance the initial HTTP Get message. Furthermore, since the requests are tied to HTTP and not transport-independent, conventional HTTP Get messages are tied to the limitations and disadvantage of HTTP, and cannot therefore benefits provided by other transport protocols.
Accordingly, systems, methods, and computer program products that provide a client computer system with the ability to request information in a highly configurable manner from another computer system on a network would be an advantage in the art. In particular, an advantage in the art can be realized with systems, methods, and computer program products that allow for rich information retrieval using a “Get” function over conventional communication protocols, without necessarily being limited to one or more of the shortcomings of using HTTP. Furthermore, an advantage in the art can be realized with such systems that provide responding computers with the ability to modify how requested information is returned.